This is bordering on something we should consider an unsupported configuration, but since we know this is a real-world setup of some customers, let's try to support it.

Before this change, our OIDC plugin could exhibit undesirable behavior in a
specific configuration edge case, which, unfortunately, matches the default
behavior of at least one identity provider software.

Specifically, Ping Identity software does not typically provide us with
JWTs that are usable for authentication and authorization, so users may
opt to use ID tokens instead. Ping, however, by default does not provide
clients with new ID tokens on a refresh operations, and also only gives
those tokens a default validity of 5 minutes.

(We do recommend to Ping customers to enable passing new ID tokens on
refresh if they have this setup.)

However, 5 minutes also happens to be the time at which the plugin
prefers either refreshing tokens or prompting the user for re-authentication
instead of re-using tokens with a short leftover validity.

This means that when the driver requests a new token multiple times, or
multiple driver instances request tokens in quick succession (which can
easily happen, especially if they used the same token beforehand, which
obviously then expires at around the same time for each driver), the
plugin would try to refresh the token, then when that failed, prompt
the user for a new authentication attempt not just once every minutes,
but multiple times in quick succession as well.

To avoid this issue, we refactor the code that chooses a token acquisition
mechanism so that even if the current token still has a leftover validity
of less than 5 minutes and refreshing fails, we still keep using it until
the driver signals to us that it has become fully unusable.